1. Field of the Invention
The present invention relates to a network device, network device management method, network device management system, and program which have a function of notifying a terminal apparatus such as a computer of device management information such as failure occurrence information.
2. Description of the Related Art
Conventionally, to manage a network device such as a multi-function device from a computer connected to a network, a network device management program is installed in the computer, thereby implementing management. The management methods are roughly classified into a polling method of causing a computer to poll a device, and a trap method of causing a device to issue a trap to a computer. For example, Japanese Patent Laid-Open No. 2001-142361 discloses a remote centralized management system using the trap method, in which a central control device manages a plurality of image forming apparatuses. Upon receiving failure information from an image forming apparatus, the central control device holds it as display information. The central control device determines the emergency level by analyzing the failure information, and if recovery from failure is necessary, transmits a reset instruction to the image forming apparatus. Recognizing recovery from failure, the central control device registers, in a log memory as log information, the failure information held as display information and erases it from the display memory.
FIG. 4 is a flowchart illustrating an operation of causing a network device management program running on a computer 400 to acquire, by polling, information from a multi-function device 401 that is a network device connected to a network. In step S400 of FIG. 4, the computer sets a timer at a predetermined polling interval set in advance, and the process advances to step S401. In step S401, time-out of the timer set in step S401 is detected, and the process advances to step S402. In step S402, the network management program running on the computer 400 transmits, to the multi-function device 401, a management information request to request management information notification, and the process advances to step S403. In step S403, the multi-function device 401 receives the management information request transmitted from the computer 400 in step S402, and the process advances to step S404. In step S404, to respond to the management information request received in step S403, the multi-function device 401 transmits, to the computer 400, a management information response including the status information of the multi-function device 401, and the process advances to step S405. In step S405, the computer 400 receives the management information response transmitted from the multi-function device 401 in step S404 and analyzes necessary management information. The computer notifies the user of necessary information obtained by analysis via the network device management program, and the process advances to step S406. From step S406, the operation in steps S400 to S405 is repeated in steps S406, S407, S409, S410, S411, S412, S413, S414, S416, S417, S418, S419.
If a failure such as paper out has occurred in the multi-function device 401 in step S408, the multi-function device 401 notifies the computer 400 of the failure occurrence by management information response transmission in step S411. In step S412, the computer 400 receives the notification and detects the failure occurrence in the multi-function device 401. Similarly, if the multi-function device 401 has recovered from the failure in step S415, the multi-function device 401 notifies the computer 400 of the recovery from the failure by management information response transmission in step S418. In step S419, the computer 400 receives the notification and detects the recovery from the failure of the multi-function device 401.
FIG. 5 is a flowchart illustrating an operation of causing a network device management program running on a computer 500 to acquire, by event notification, information from a multi-function device 501 that is a network device connected to a network. In step S500 of FIG. 5, a failure such as paper out occurs in the multi-function device 501, and the process advances to step S501. In step S501, the multi-function device 501 notifies the computer 500 of the failure occurrence by management information notification. The computer 500 receives the management information notification in step S502, and the process advances to step S503. In step S503, the computer 500 notifies, by failure information notification response, the multi-function device 501 that it has correctly received the management information sent in step S501. The device receives the response in step S504. In steps S505, S506, S507, S508 and S509, the multi-function device 501 notifies the computer 500 of recovery from the failure.
In both cases, information to be handled depends on implementation of the network device management program running on the computer. If the capability of the multi-function device is expanded, the network device management program must be reinstalled.
A notification may be sent to the PC by e-mail, instead of using the network device management program. All the above-described methods are advantageous because the client PC can receive notifications from the device without omission. However, the network device management program requires upgrade to harmonize with a change on the device side. To use e-mail, it is necessary to prepare a mechanism for creating mail and a mail server on the device side.
Against this backdrop, a technique of causing a device to distribute summary information of, for example, a device error or event to a client terminal using RSS (short for RDF Site Summary) as an information management and notification means is also being developed. RSS is a technique of distributing the heads, summaries, and links of articles on Web sites. A Web site generates RSS information (also referred to as syndication data) based on the heads, summaries, and links of articles updated on Web pages. The RSS information is a source described in an RSS format based on XML. The RSS format has several versions such as RSS0.91, RSS2.0, RSS1.0, and Atom. Any version is usable if the client supports it. The client executes an application program called an RSS reader, and if there is information (called update information) newly generated on a selected Web site, receives it. That is, the RSS reader acquires the update information of a selected Web site and displays it on the screen by periodically downloading generated RSS information. If the Web page has links, the user can jump to the Web page of each article. Using the RSS, it looks for the user as if the update information were distributed from the selected Web site. This allows the user to efficiently browse interesting pages in an enormous number of HTML pages.
A method of notifying a user of the status information of a plurality of printers using the RSS technique is proposed in, for example, Japanese Patent Laid-Open No. 2005-209056. Japanese Patent Laid-Open No. 2005-209056 proposes a printer having a function of providing the device state as data in an RSS format. The printer generates an HTML page representing the device state, and then generates, based on the HTML page, RSS information containing the heads and summaries of pages, and links to HTML pages of the source. A user who wants to receive notifications registers the URL of the collection target site in the RSS reader on the client PC. This enables the user to easily grasp the contents of printer state changes using a Web browser program. The use of the RSS allows the client to monitor occurrence of an event such as failure using a general-purpose browser incorporating an RSS reader. This obviates new development or upgrade of software in a client and enables a client to very flexibly cope with a change on the network device side. Even when an event such as failure to notify changes due to, for example, change of the model or update of software, it is unnecessary to change the Web browser or RSS reader in the client. It brings about significant advantages because a network device is generally shared by a number of clients. The device need only have an HTML server program in it to distribute HTML pages, and also a mechanism for generating the HTML pages and RSS information. Additionally, notification contents are described in an RSS format, that is, a general-purpose format based on XML and are therefore restricted by only implementation upon RSS information generation.
However, RSS restricts information to notify by a number or time limit. Pieces of update information beyond a predetermined number or time limit are generally deleted. Hence, if the number of update information exceeds the upper limit, or some pieces of update information have expired, information to notify the user to failure occurrence may be deleted independently of the current state of the multi-function device. Even when a failure that requires intervention of an operator or the like has occurred, the operator may be unaware of it. For this reason, RSS is inappropriate as a failure occurrence notification means.